IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks (3GPP TS 22.228). IMS provides key features to enrich the end-user person-to-person communication experience through the integration and interaction of services. IMS allows new rich person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (UEs) or between UEs and application servers (ASs). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. Both SIP and SDP are carried by standard UDP and TCP internet protocols. SIP or SDP messages below 1300 bytes will be transported via UDP; else TCP is used to transport them.
Within an IMS network, Call/Session Control Functions (CSCFs) operate as SIP entities within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
IMS service functionality is implemented using application servers (ASs). For any given UE, one or more ASs may be associated with that terminal. ASs communicate with an S-CSCF via the IMS Service Control (ISC) interface and are linked into a SIP messaging route as required (e.g. as a result of the triggering of IFCs downloaded into the S-CSCF for a given UE).
A user registers in the IMS using the specified SIP REGISTER method. This is a mechanism for attaching to the IMS and announcing to the IMS the address at which a SIP user identity can be reached. In 3GPP, when a SIP terminal performs a registration, the IMS authenticates the user using subscription information stored in a Home Subscriber Server (HSS), and allocates a S-CSCF to that user from the set of available S-CSCFs. Whilst the criteria for allocating S-CSCFs are not specified by 3GPP, these may include load sharing and service requirements. It is noted that the allocation of an S-CSCF is key to controlling, and charging for, user access to IMS-based services. Operators may provide a mechanism for preventing direct user-to-user SIP sessions which would otherwise bypass the S-CSCF.
During the registration process, it is the responsibility of the I-CSCF to select an S-CSCF, if an S-CSCF is not already selected. The I-CSCF receives the required S-CSCF capabilities from the HSS, and selects an appropriate S-CSCF based on the received capabilities. It is noted that S-CSCF allocation is also carried out for a user by the I-CSCF in the case where the user is called by another party, and the user is not currently allocated an S-CSCF. When a registered user subsequently sends a session request to the IMS, the P-CSCF is able to forward the request to the selected S-CSCF based on information received from the S-CSCF during the registration process.
Every IMS user possesses one or more Private User Identities. A Private User Identity is assigned by the home network operator and is used by the IMS, for example for registration, authorisation, administration, and accounting purposes. This identity takes the form of a Network Access Identifier (NAI) as defined in IETF RFC 2486. It is possible for a representation of the International Mobile Subscriber Identity (IMSI) to be contained within the NAI for the private identity. 3GPP TS 23.228 specifies the following properties of the Private User Identity:                The Private User Identity is not used for routing of SIP messages.        The Private User Identity shall be contained in all Registration requests, (including Re-registration and De-registration requests) passed from the UE to the home network.        An IP multimedia Services Identity Module (ISIM) application shall securely store one Private User Identity. It shall not be possible for the UE to modify the Private User Identity information stored on the ISIM application.        The Private User Identity is a unique global identity defined by the Home Network Operator, which may be used within the home network to identify the user's subscription (e.g. IM service capability) from a network perspective. The Private User Identity identifies the subscription, not the user.        The Private User Identity shall be permanently allocated to a user's subscription (it is not a dynamic identity), and is valid for the duration of the user's subscription with the home network.        The Private User Identity is used to identify the user's information (for example authentication information) stored within the HSS (for use for example during Registration).        The Private User Identity may be present in charging records based on operator policies.        The Private User Identity is authenticated only during registration of the user, (including re-registration and de-registration).        The HSS needs to store the Private User Identity.        The S-CSCF needs to obtain and store the Private User Identity upon registration and unregistered termination.        
In addition to a Private User Identity, every IMS user shall have one or more IMS Public User Identities (PUIs). The PUIs are used by any user to request communications to other users. A user might for example include a PUI (but not a Private User Identity) on a business card. 3GPP TS 23.228 specifies the following properties of the PUI:                Both telecom numbering and Internet naming schemes can be used to address users depending on the PUIs that the users have.        The PUI(s) shall take the form of a SIP URI (as defined in RFC 3261 and RFC 2396 or the “tel:”-URI format defined in RFC 3966.        An ISIM application shall securely store at least one PUI (it shall not be possible for the UE to modify the PUI), but it is not required that all additional PUIs be stored on the ISIM application.        A PUI shall be registered either explicitly or implicitly before the identity can be used to originate IMS sessions and IMS session unrelated procedures.        A PUI shall be registered either explicitly or implicitly before terminating IMS sessions and terminating IMS session unrelated procedures can be delivered to the UE of the user that the PUI belongs to.        It shall be possible to register globally (i.e. through one single UE request) a user that has more than one PUI via a mechanism within the IMS (e.g. by using an Implicit Registration Set). This shall not preclude the user from registering individually some of his/her PUIs if needed.        PUIs are not authenticated by the network during registration.        PUIs may be used to identify the user's information within the HSS (for example during mobile terminated session set-up).        PUIs may be used by ASs within the IMS to identify service configuration data to be applied to a user.        
An IMS user has one or more IMS subscriptions. The IMS subscription has one Private User Identity and at least one Service Profile. The Service Profile contains at least one Public User identity. A Public User Identity can only be associated to one Service Profile where the Private User Identity can be associated with more than one Service profile. FIG. 1 illustrates schematically example relationships between a user of the IMS, his IMS subscriptions and the Public and Private User Identities. In the example shown, a subscriber has two Private User Identities each associated with one IMS subscription, with both being associated with two Public User Identities (one of the Public User Identities, Public User Identities-2, being associated with both Private User Identities). A Service Profile is associated with each Public User Identity, this profile specifying service data for the associated Public User Identities. A Service Profile is created or modified when an application server is provisioned for a user at the Home Subscriber Server (HSS). Each Service Profile comprises one or more initial Filter Criteria (iFC) which are used to trigger the provision, or restriction, of IMS services. The differences between services offered by Service Profile-1 and Service Profile-2 are operator specific, but may involve different application servers (ASs), and even different charging/rating schemes.
In the example, Public User Identity-1 is associated with a Service Profile-1, whilst Public User Identity-2 and Public User Identity-3 are associated with Service Profile-2. In a typical scenario, the Public User Identity-1 might be an identity that the user gives to friends and family, e.g. “Big_Joe@priv.operator.com”, whilst Public User Identity-2 and Public User Identity-3 might be identities that the user gives to business contacts, e.g. “+46111222333@operator.com” and “joe.black@operator.com”.
3GPP defines a so-called “Implicit Registration Set” concept to identify a set of PUIs that work as a group, and which are registered and deregistered together when any one of the PUIs of the set is registered or deregistered. Upon registration of an IMS user's terminal or upon receiving a connection request for the user's terminal when not yet registered, the S-CSCF, after triggering by an I-CSCF, requests the subscription details (also denoted as user profile) from the HSS, identified by the Private and Public User Identity received in the trigger from the I-CSCF. As described above the subscription (user profile) contains one or more Service Profiles and each Service Profile contains one or more Public User Identities. See for example User Profile 1 in FIG. 1. All the Public User Identities in the User profile together are denoted the Implicit Registration Set.
For purpose of understanding a more detailed description of the standard registration procedure is given hereafter with reference to FIG. 2. Before a UE can set-up a session or incorporate IMS services it needs to register in the IMS. In the following example Joe Black registers under his Public Identity “Big_Joe@operator1.com” in the IMS of Operator 1 where he has an IMS subscription. FIG. 1 gives an overview of the messages. The actual registration process consists of 2 phases. In the first phase a not secured register is send to the S-CSCF. The S-CSCF authenticates the UE/PUI in a first step and sends back a challenge to the UE with a SIP 401 message. The UE uses the challenge to calculate a response that is sent in a subsequent REGISTER message for phase 2 of the registration. Besides calculating the response this intermediate between the two phases is also used by the UE to negotiate a secure IP channel (IP-Sec) with the P-CSCF. When the S-CSCF receives the second register it completes the authorisation and registers the UE/PUI. When registration is completed a SIP 200 message is send back to the UE. After completing the registration the S-CSCF further registers the PUI at all relevant IMS applications as indicated by the iFC's in the user profile obtained from the HSS.
Before the UE can assemble the REGISTER message it needs to acquire the IP address of the P-CSCF. This address can be stored in the UE but more likely only an alias of the P-CSCF is stored and the UE requires getting the correct IP address via DHCP and/or DNS. The UE then assembles the REGISTER message and sends it towards the P-CSCF. The message (1 of FIG. 2) is given below in simplified form. Only fields relevant for the explanation of the current invention are discussed.
*************************************************************REGISTER sip: operator1.comVia: <current IP of Joe Blacks UE>; branch=0uetbRoute: <current IP address of P-CSCF>Max-Forwards: 50From: Big_Joe@operator1.comTo: Big_Joe@operator1.comContact: <current IP of Joe Blacks UE>; expires=2000Call-ID: grt38u6yqr54gfkp98y6t3rrCSeq: 25 REGISTERContent-Length: 0*************************************************************
The type of message is REGISTER. Cseq and Call-ID give a unique identification of this register transaction. The message is basically only a message header without payload (like voice or video packages) hence Content-Length is set to 0. The initial destination is given by “SIP: operator1.com” as that is where the UE wants to register. The From field gives the Public User Identity of Joe Black which he wants to use. The To field is identical, as that is for which prime registration is requested. The Contact field contains the current IP address of the UE, expires indicates the remaining lease period when the IP address is leased for a definite period of time. It indicates how long the SIP URI in the To field is bound to the IP address in the Contact field.
The Route field contains each time the next SIP entity the message is sent to. Each SIP entity the message past through will add it self in a Via header as to create so a return path. The Max-Forwards is lowered by one after passing each SIP entity to prevent that the message starts bouncing in the IP network. When the value becomes 0 the message is deleted.
When the message arrives at the P-CSCF, the P-CSCF removes its own address from the route header and puts it in a Via header. Then the P-CSCF starts investigation on which I-CSCF to forward the message to. This I-CSCF can be in another network of another operator. It therefore uses the requested URI in the REGISTER field and DNS to resolve the domain name and subsequent DNS, NAPTR, SRV and AAAA queries to obtain an I-CSCF address. The P-CSCF can however not be sure that the I-CSCF will perform the SIP entity function or just act as a router to just another I-CSCF. It there fore does not put the address in the route field but in the destination field of an underlying UDP message that transports the SIP register message. Additionally the P-CSCF includes a Path field with its own identity. The S-CSCF can use the Path field as the exact location to send any future responses to the UE as the UE it self is shielded, the P-CSCF is the entrance of a secure IP tunnel to the UE. The message 2 send now looks like;
*************************************************************REGISTER sip: operator1.comVia: <current IP address of P-CSCF>; branch=0pctbVia: <current IP of Joe Blacks UE>; branch=0uetbRoute: Path: current IP address of P-CSCF>Max-Forwards: 49From: Big_Joe@operator1.comTo: Big_Joe@operator1.comContact: <current IP of Joe Blacks UE>; expires=2000Call-ID: grt38u6yqr54gfkp98y6t3rrCSeq: 25 REGISTERContent-Length: 0*************************************************************
When received, the I-CSCF puts its address in a Via header. Then it requires obtaining the address of the S-CSCF. It therefore does a Location Information Request 3 to the HSS. The HSS responds with a Location Information Answer 4. It then uses the obtained S-CSCF address or determines a S-CSCF address and puts in the Route field. Message 5 looks now like;
*************************************************************REGISTER sip: operator1.comVia: <current IP address of S-CSCF>; branch=0ictbVia: <current IP address of P-CSCF>; branch=0pctbVia: <current IP of Joe Blacks UE>; branch=0uetbRoute: < current IP address of S-CSCF>Max-Forwards: 48From: Big_Joe@operator1.comTo: Big_Joe@operator1.comContact: <current IP of Joe Blacks UE>; expires=2000Call-ID: grt38u6yqr54gfkp98y6t3rrCSeq: 25 REGISTERContent-Length: 0*************************************************************
Now the S-CSCF has received the message it starts first with verifying whether the requested registration is possible, PUI is known. It therefore does a Location Information Request 6 to the HSS. The HSS responds with a Location Information Answer 7. The PUI is known but registration is denied as full authentication has not yet been performed. Therefore the S-CSCF sends a 401 unauthorised message back to the UE. This message contains the WWW-authenticate field that contains the challenge keys. Full details of the authentication and security aspects can be found in 3GPP TS 33.203 and RFC 3329.
The message follows the same route back to the UE via messages 8, 9 and 10. The route back is indicated by the Via fields assembled during the transport to the S-CSCF. Each SIP entity removes the first Via header (being it self) and routes to the next Via header. In addition the I-CSCF includes a Service-Route field. The UE can use this for all other message then the REGISTER message so the P-CSCF is released from performing the tedious task of allocating the correct I-CSCF each time.
The UE receiving the 401 not authorised message now continues with the negotiation of a secure IP tunnel with the P-CSCF. It then calculates a response for the P-CSCF and one for the S-SCSF. The first one being for establishing the secure connection to the P-CSCF the second one for the S-CSCF to complete the authorisation and perform the registration. The responses of the UE are contained in the authorisation field of a second REGISTER message. The following flow of messages 11, 12, 13, 14, and 15 is identical to the previous REGISTER messages flow 1, 2, 3, 4, and 5.
The S-CSCF now checks if the challenge response is correct and then continues with a Location Information Request 16 to the HSS. The HSS responds with a Location Information Answer 17. The answer contains the User Profile as determined by the HSS on basis of the Private User Identity and Public User Identity as given in the request by the S-CSCF. The User Profile provides the S-CSCF the Implicit registration set of all Public User Identities that associated with the Private user identity including the Service Profiles associated with the PUI's. These PUI's are so implicitly registered with the PUI in the REGISTER message. The IP address of the UE is bound to the PUI's for a period no longer then what is expressed in the expire field of the REGISTER message. This period can be less depending on the operator policies for maximum registration period.
First step now is that the S-CSCF sends a 200 OK message to the UE in the same way as the 401 not authorised message. This message flow is indicated by messages 18, 19 and 20.
As second step the S-CSCF uses the iFC fields in the Service Profiles contained in the User Profile to register the PUI of the REGISTER message with the IMS applications as indicated in the iFC fields. Note that the application is only informed of the one PUI in the REGISTER messages 21 to the applications. For obtaining information on the other PUI implicitly registered they need to subscribe to registration-state (change) information at the S-CSCF. Like wise the UE needs to subscribe directly after getting the 200 OK message to get information on the registration state of other implicitly registered PUI's.
The above described registration is kept to the mere basics required to understand the merits of the current invention. For a more detailed description reference is made to state of the art manuals as “The IMS” ISBN 978-0-470-01906-1.
In the case of Joe Black described before, one user had one subscription with multiple PUI's. Another possible use case of the IMS involves a collection of users having a group level subscription to the IMS, but where the individual users themselves have no subscription. In general the group is shielded by means of an access point that takes care of handling SIP sessions towards the IMS on behalf of the group.
Instead of the group the access point registers in the IMS, comparable to a UE. Nonetheless, it is desirable or even necessary to allow direct inward and outward dialing to those users. This might arise, for example, in the case of an enterprise having a subscription to the IMS and having individual employee stations or terminals attached to an IP private branch exchange (IP-PBX). The employee terminals may or may not be provided with SIP clients. In the latter case, the IP-PBX performs a translation between SIP and non-SIP signalling. Whilst it might of course be possible for the IMS to record an individual PUI for each terminal (within the same Implicit Registration Set), this becomes inefficient as the group size becomes large. ETSI TISPAN defines such a corporate network as a Next Generation Corporate Network (NGCN).
An alternative solution is illustrated schematically in FIGS. 3 and 4 which shows an IP-PBX (designated “IP-PBX1” and “IP-PBX 2”) as access point which serves a plurality of user terminals. One calling terminal is shown as extension 1234 and one is shown as “Ext. 5678”. The first terminal is requesting a session to the second one. User at enterprise 1 and 2 have a dedicated Business Trunk application (BT-AS) in the IMS. This application requires having the identity of the calling/originating or called/terminating party to provide certain services. This solution employs the so-called Public Service Identity (PSI) which identifies publicly available network-based IMS services for users. The solution defines within the HSS, in a Service Profile of the subscription for the IP-PBX, a wild carded PSI, which matches the PUIs specified for the terminals belonging to an IP-PBX, giving access to certain applications in the IMS. The solution provides workarounds for calling and called cases using a PSI in conjunction with the BT-AS for the purpose of user to user sessions. The registration of IP-PBX1 and 2 is identical to that of a regular UE in that the IP-PBX registers with his own PUI.
FIG. 3 illustrates a workaround solution for the originating (calling) case, i.e. where a terminal behind a PBX initiates a call to a remote terminal. The IP-PBX1 belongs to enterprise1) and has as own PUI “PBX1@operator1.com”. IP-PBX1 has as group code 850 and as number range +31 161 24 xxxx. An employee Alice requests to set up a session from her terminal with extension 1234 to Bob at enterprise 2 having extension 5678 behind a IP-PBX 2 with group code 851 as defined by IP-PBX1.
The request 101 of Alice is received at IP-PBX1 that assembles the outgoing request 102 towards the P-CSCF. The format of the message looks like;
*************************************************************INVITE Tel: +31161255678From: Alice <Tel: 8501234>To: Bob <Tel: 8515678; phone-context=enterprise1.com>P-Preferred-Identity: Tel: +31161241234*************************************************************
When received the outbound P-CSCF does not recognise the P-Preferred. Identity contained within the INVITE. It uses as a default P-Asserted-Identity the PUI of IP-PBX1, namely “pbx1@operator1.com”. The message 103 now send by the P-CSCF to the S-CSCF looks like;
*************************************************************INVITE Tel: +31161255678From: Alice <Tel: 8501234>To: Bob <Tel: 8515678; phone-context=enterprise1.com>P-Asserted-Identity: pbx1@operator1.com*************************************************************
At the S-CSCF, it uses the P-Asserted-Identity of the message to check the user profile of IP-PBX1 and finds a service profile with an IFC telling the S-CSCF to involve the BT application. The S-CSCF therefore sends 104 the INVITE message as received to the BT application. The BT application server validates and asserts that the originating user is the user that is identified in the “From” header, and replaces the P-Asserted-Identity header with the identity of the calling user, namely “tel:+31161241234”. The BT application returns the INVITE message 105 modified with a new asserted ID for Alice. The message now looks like;
*************************************************************INVITE Tel: +31161255678From: Alice <Tel: 8501234>To: Bob <Tel: 8515678; phone-context=enterprise1.com>P-Asserted-Identity: Tel: +31161241234*************************************************************
Back at the S-CSCF it has to perform an ENUM lookup 106 to translate the requested Tel URI into a known SIP URI. The adapted INVITE message 107 is then send to the Interconnected Border Control Function, (I-BCF) of operator 1 for further transport to the network of operator 2. The finally INVITE message looks like;
*************************************************************INVITE SIP: +31161255678@operator2.com;user=phoneFrom: Alice <Tel: 8501234>To: Bob <Tel: 8515678; phone-context=enterprise1.com>P-Asserted-Identity: Tel: +31161241234*************************************************************
Further referring to FIG. 4 the INVITE message arrives at the I-BCF of operator 2. It will forward the message as received 201 to an I-CSCF. The I-CSCF will recognise a SIP request URI corresponding to a telephone number and will convert this to a Tel URI. In this example of Alice to Bob connection, the SIP request URI is “sip:+31161255678@operator2.com, user=phone”, and this is converted to the Tel URI “Tel: +31161255678”. The I-CSCF then sends a Location Information Request 202 to the HSS according to normal IMS procedures. The HSS determines that the Tel URI matches a PSI wildcard, and responds with a Location Information Answer 203 to the I-CSCF with the identity of the allocated S-CSCF. The same mechanism is used here that is used for a not yet registered terminal having at least subscribed to one application. The I-CSCF forwards the SIP message 204 to the allocated S-CSCF. The message looks then like;
*************************************************************INVITE Tel: +31161255678From: Alice <Tel: 8501234>To: Bob <Tel: 8515678; phone-context=enterprise1.com>P-Asserted-Identity: Tel: +31161241234*************************************************************
Next the S-CSCF act as it would act for a not yet registered terminal. It obtains the User profile from the HSS that contains at least one service profile with a matching wild carded PSI from the HSS. This profile includes an IFC trigger which causes the S-CSCF to route the message 205 to a Business Trunking application server (BT-AS). The application server replaces the SIP request URI “Tel: +31161255678” with the address of IP-PBX 2, namely “pbx2@operator2.com”, and inserts the destination address into the To header field, deleting the previous content which is now lost. The returned message 206 look now like;
*************************************************************INVITE PBX2@operator2.comFrom: Alice <Tel: 8501234>To: Tel: +31161255678P-Asserted-Identity: Tel: +31161241234*************************************************************
As now a new URL is in the INVITE requested field, the S-CSCF has to forward the message 207 as received from the BT-AS to an I-CSCF as the request URI has changed and hence a new terminating party is targeted. The message then arrives at a further I-CSCF which does a Location Information Request 208 to the HSS to determine the S-CSCF allocated to IP-PBX2 before delivering the message to that allocated S-CSCF. The HSS provides a Location Information Answer 209 and the I-CSCF forwards the INVITE message 210 to the S-CSCF.
As IP-PBX2 is most likely already registered the S-CSCF knows the contact address for IP-PBX2. Before sending the INVITE request to the P-CSCF for IP-PBX2 first the iFCs in the service profiles of the user profile for IP-PBX2 are checked for triggers to further IMS applications as indicated as an option by message 211 and return message 212. When no triggers or after response of the last application, the S-CSCF adds the contact address for IP-PBX2 as the new requested URI. In order to preserve the old URI, “pbx2@operator2.com”, the S-CSCF adds a P-Called-Party-Id containing this URI. The message 213 forwarded to the P-CSCF now looks like;
*************************************************************INVITE PBX2-contact-addressFrom: Alice <Tel: 8501234>To: Tel: +31161255678P-Asserted-Identity: Tel: +31161241234P-Called-Party-ID: PBX2@operator2.com*************************************************************
The P-CSCF forwards the message 214 to IP-PBX2 as instructed in the INVITE header The IP-PBX2 is responsible for setting up the connection to the terminal of Bob trough the corporate network of enterprise2. In the case where the destination terminal is a SIP terminal, upon receipt of the message, IP-PBX 2 can arrange for delivery of the message to the terminal based upon the address contained in the “To” header field. If the destination terminal is not a SIP terminal, the IP-PBX 2 terminal will handle the termination according to some application specific logic.
The “workaround” solution illustrated in FIG. 2 has the disadvantage that it requires two traversals of a CSCF complex. This will result in increased message transit times. In addition, the information originally contained in the “To” header is lost, as is the original request URI that was inserted by the caller. Without the original “To” header, certain applications at the called terminal may not function. In addition the workaround requires that a BT application or something with similar function must available to be able to create a correct P-Asserted-ID.
Instead of an IP-PBX as given in this workaround the company can use a standard RFC 3261 SIP proxy server for SIP enabled mobile terminals. Also in this case the company can have a group subscription to IMS rather then individual subscriptions. The basic operation for a SIP proxy server is identical to that for an IP-PBX in that for a call terminating case the requested URI should contain the address of the SIP proxy server. It is to the SIP proxy server to retrieve the final destination from the “To” header.
The main problem of the above described workarounds is that the original requested URI is replaced by the IP-PBX or SIP proxy server address in case of group subscriptions. To be able to route the invite message to the final destination modifications are required in the IP-PBX or SIP proxy server that work according the RFC 3261 standard as this standard expects the final destination to be in the requested URI.
Where it would be possible to design workarounds for specific cases this introduces also a more essential problem. When adapting nodes of the IMS they must be capable of handling both, users that require a work around and those not needing it as they can be handled in a standard way. Nodes could be made specific for dedicated user groups but from an operational point of view this situation is unwanted.